Sign only the parameters Cloudinary verifies, unbreaking uploads - #187

Photo upload has been failing with Invalid Signature. The server signed four parameters; Cloudinary verifies three.

Cloudinary signs only the upload parameters it recognises and silently drops the rest. max_file_size is not one of them, so including it produced a signature that could never match. Its own error said so — the String to sign it echoed back listed folder, timestamp, upload_preset, and nothing else.

Not a regression from #185. That PR never touched media.ts or the client upload path. This dates from whenever max_file_size entered the signature and has been broken ever since; nobody noticed because nobody had uploaded a photo through the UI in between.

The comment is what caused this

// Enforced on the signature itself so a leaked signature can't be reused to
// upload a bigger file than we allow.

A reasonable-sounding guarantee that Cloudinary does not offer. Someone read it and wired the limit into the signature. It's replaced with what's true: the limits are advisory, they feed the client-side check, and the only enforceable ceiling is whatever the upload presets have configured in the Cloudinary console.

The client stops sending max_file_size too — Cloudinary ignores it, so it bought nothing but the appearance that the limit went somewhere meaningful. The size check that gives a useful error before a doomed upload stays, and the callable still returns maxFileSize to feed it.

The test that should have caught this, and why it didn't

"signs exactly the parameters it returns" already carried this comment:

If the handler ever signs a different set of params than it hands back, Cloudinary rejects every upload.

It was right. It also passed — because it recomputed the same wrong set the handler used. max_file_size was on both sides of that comparison and on neither side of Cloudinary's. A test that mirrors the implementation cannot catch the implementation being wrong about a third party.

Its list is now written as the contract with Cloudinary rather than a copy of what the handler does, with a note not to add a parameter without confirming Cloudinary signs it. The sibling test that claimed the limit was "bound into the signature" is retitled and its comment corrected.

Two things I could not verify

1. Whether the upload presets carry a max file size. I cannot read the Cloudinary console from the repo. If petnote_image_signed / petnote_video_signed have no limit configured, then after this change there is no server-side size ceiling at all — only the advisory client check, which a crafted request skips. Worth checking before launch; if it's unset, that's a separate PR to set it.

2. That uploads actually work again. Local lint and build pass for both trees, and CI runs the emulator suite here — but none of that touches Cloudinary. This is precisely the class of bug CI cannot catch, which is the whole point of this PR. A real upload has to happen after deploy before this is called done.

🤖 Generated with Claude Code